Traditionally a video on demand service, such as that provided commercially in the UK under the trade name BT Vision, is supported by encoding video at a constant bit rate and delivering it over a network at the same constant bit rate. This generally requires bandwidth reservation on the network, which can be expensive to provide. Video encoded using compression techniques naturally has variable bit rate, as the number of bits produced when encoding a picture depends on the picture content: how similar it is to previously encoded pictures and how much detail it contains. Some video scenes can be coded to a given quality with a small number of bits, whereas other scenes may require significantly more bits to achieve the same quality. When constant bit rate (CBR) encoding is used, video has to be coded at time varying quality to meet the bit rate constraint. This has been shown to be sub-optimal to the user, who would prefer to see constant quality. Also, by fixing the bit rate independent of the genre of the video content, some genres of content can be encoded well, such as news and drama, whereas others, such as fast moving sport and music videos and concerts, can only be coded quite poorly.
In order to address the perceived image quality issues with CBR encoded video, variable bit rate (VBR) encoded video can be provided, where the video is encoded at a variable rate so as to provide for substantially constant quality. In this respect, WO 2009/112801, incorporated herein by reference in its entirety for all purposes, describes how video data may be encoded to allow for substantially constant perceived quality on the part of a viewing user. However, due to the variability of instantaneous bit rate of VBR encoded data, delivery of variable bit rate encoded data over a network can itself be problematic, if the network is to deliver the data sufficiently quickly such that all video data is delivered in time for it to be decoded and displayed without interruption. In particular, parts of the VBR encoded data which have a high number of bits per frame, such as action sequences or the like, may lead to high instantaneous data rate requirements which the network is unable to deliver. Such situations may then lead to buffer underflow at the decoding client, and hence interruptions in delivery.
In order to avoid such buffer underflow conditions occurring it is therefore important to control carefully the data transfer rate and video data quality (which itself dictates the amount of data to be delivered) such that quality can be improved where possible, whilst preventing buffer underflow conditions occurring.
Our prior co-pending European patent applications EP10252205.9 (Agent ref: A32153 CALCULATING DELIVERY BIT RATES USING ADDITIONAL CRITICAL POINTS) and EP10252204.2 (Agent Ref: A32154 CALCULATING DELIVERY BIT RATES USING DOWNSTAIRS POINTS) (the contents of both of which being incorporated herein by reference for all purposes) describe techniques for calculating forward delivery rates required for VBR encoded data dependent on received delivery rates and the cumulative bit profile with respect to time of the encoded data file. Herein the cumulative bit profile is referred to as the cumulative bit curve (CBC), and is a monotonically increasing curve, the gradient of which at any time is dependent on the encoding of the original data file. For example, in the case of a video file with a fast moving action sequence, there will be more bits required per Group of Pictures (GoP), and hence the gradient of the cumulative bit curve will be steeper than for a scene which is slow moving, or little changing. In this respect, the cumulative bit curve is not usually a continuous curve, but instead made of discrete data points corresponding to each GoP in a video sequence.
As will be described below, the CBC is required in the calculation of forward delivery rates using the techniques described in the above referenced European patent applications and described further below. However, as will be apparent the techniques require knowledge of the whole CBC at the video client, and hence CBC data needs to be transferred across a network from a video server to a video client prior to the start of streaming of the actual content. At its simplest the data comprises tables of cumulative bit values per GoP for a VBE encoded file, and can be sizable, typically several hundred kilobytes. This can impose a significant network overhead and/or time delay in starting streaming, and hence is undesirable. It would therefore be beneficial if an alternative to having to provide such tables of data could be provided.